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INTRODUCTION 


The  Ada  implementation  described  above  was  tested  according  to  the  Ada 
Validation  Procedures  tPro92)  against  the  Ada  Steuidard  tAda83]  using  the 
current  Ada  Coirpiler  Validation  Capability  (ACVC).  Itiis  Validation  Summary 
Report  (VSR)  gives  an  account  of  the  testing  of  this  Ada  implementation.  For 
any  technical  terms  used  in  this  report,  the  reader  is  referred  to  lPro92]. 
A  detailed  description  of  the  ACVC  nay  be  found  in  the  current  ACVC  User's 
Guide  [UG89]. 


1.1  USE  OF  THIS  VALIDATIC^I  SUMMARY  REPORT 

Consistent  with  the  national  laws  of  the  originating  country,  the  Ada 
Certification  Body  may  make  full  and  free  public  disclosure  of  this  report. 
In  the  United  States,  this  is  provided  in  accordance  with  the  "Freedom  of 
Information  Act"  (5  U.S.C.  #552).  Hie  results  of  this  validation  apply  only 
to  the  conputers,  operating  systems,  and  compiler  versions  identified  in  this 
report. 

The  organizations  represented  on  the  signature  page  of  this  report  do  not 
represent  or  warrant  that  all  statements  set  forth  in  this  report  are 
accurate  emd  complete,  or  that  the  subject  implementation  has  no 
nonconformities  to  the  Ada  Standard  other  than  those  presented.  Copies  of 
this  report  are  available  to  the  public  from  the  AVF  which  performed  this 
validation  or  from: 

National  Technical  Information  Service 
5285  Port  Royal  Road 
Springfield  VA  22161 

Questions  regarding  this  report  or  the  validation  test  results  should  be 
directed  to  the  AVF  which  performed  this  validation  or  to: 

Ada  Validation  Organization 

Computer  and  Software  Engineering  Division 

Institute  for  Defense  Analyses 

1801  North  Beauregard  Street 

Alexandria  VA  22311-1772 
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1.2  REFERENCES 

[Ada83]  Reference  Mcinual  for  the  Ada  Proqraitming  Language. 

ANSI/MIL-STD-181Sa,  February  1983  and  ISO  8652-1987. 

[Pro92]  Ada  Compiler  Validation  Procedures,  Version  3.1,  Ada  Joint 
Program  Office,  August  1992. 

[UG89]  Ada  Compiler  Validation  Capability  User's  Guide,  21  June  1989. 


1.3  ACVC  TEST  CLASSES 

Compliance  of  Ada  implementations  is  tested  by  mezuis  of  the  ACVC.  The  ACVC 
contains  a  collection  of  test  programs  structured  into  six  test  classes:  A, 
B,  C,  D,  E,  and  L.  The  first  letter  of  a  test  name  identifies  the  class  to 
which  it  belongs.  Class  A,  C,  D,  and  E  tests  are  executedjle.  Class  B  and 
class  L  tests  are  expected  to  produce  errors  at  compile  time  and  link  time, 
respectively. 

The  executadale  tests  are  written  in  a  self-checking  maurmer  and  produce  a 
PASSED,  FAILED,  or  NOT  APPLICABLE  message  indicating  the  result  when  they  are 
executed.  Three  Ada  library  \inits,  the  packages  REPORT  and  SPPRT13,  and  the 
procedure  CHECK_FILE  are  used  for  this  purpose.  The  package  REPORT  also 
provides  a  set  of  identity  fxmctions  used  to  defeat  some  compiler 
optimizations  allowed  by  the  Ada  Standard  that  would  circumvent  a  test 
objective.  The  package  SPPRT13  is  used  by  many  tests  for  Chapter  13  of  the 
Ada  Standard.  The  procedure  CHECK_FILE  is  used  to  check  the  contents  of  text 
files  written  by  some  of  the  Class  C  tests  for  Chapter  14  of  the  Ada 
Standard.  The  operation  of  REPORT  and  CHECK_FILE  is  checked  by  a  set  of 
executcible  tests.  If  these  units  are  not  operating  correctly,  validation 
testing  is  discontinued. 

Class  B  tests  check  that  a  conpiler  detects  illegal  leinguage  usage.  Class  B 
tests  are  not  executa±)le.  Each  test  in  this  class  is  compiled  and  the 
resulting  conpilation  listing  is  examined  to  verify  that  all  violations  of 
the  Ada  Standard  are  detected.  Some  of  the  class  B  tests  contain  legal  Ada 
code  which  must  not  be  flagged  illegal  by  the  conpiler.  This  behavior  is 
also  verified. 

Class  L  tests  check  that  an  Ada  inplementation  correctly  detects  violation  of 
the  Ada  Standard  involving  multiple,  separately  compiled  units.  Errors  are 
expected  at  link  time,  euad  execution  is  attempted. 

In  some  tests  of  the  ACVC,  certain  macro  strings  have  to  be  replaced  by 
implementation-specific  values  —  for  excunple,  the  largest  integer.  A  list 
of  the  values  used  for  this  inplementation  is  provided  in  Appendix  A.  In 
addition  to  these  anticipated  test  nsxiifications,  additional  changes  may  be 
required  to  remove  unforeseen  conflicts  between  the  tests  and 
implementation-dependent  characteristics.  The  modifications  required  for 
this  implementation  are  described  in  section  2.3. 
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For  each  Ada  implementation,  a  customized  test  suite  is  produced  by  the  AVF. 
This  customization  consists  of  making  the  modifications  described  in  the 
preceding  paragraph,  removing  withdrawn  tests  (see  section  2.1),  and  possibly 
removing  some  inapplicable  tests  (see  section  2.2  and  [UG89]). 

In  order  to  pass  an  ACVC  cin  Ada  inplementation  must  process  each  test  of  the 
customized  test  suite  according  to  the  Ada  Standard. 


1.4  DEFINITION  OF  TERMS 

Ada  Compiler  The  software  and  any  needed  hardware  that  have  to  be  added  to 
a  given  host  and  target  computer  system  to  allow 
treinsformation  of  Ada  progreims  into  executable  form  and 
execution  thereof. 

Ada  Conpiler  The  mecins  for  testing  conpliance  of  Ada  implementations, 
Validation  consisting  of  the  test  suite,  the  support  progreuns,  the  ACVC 

Capc±)ility  user's  guide  eind  the  template  for  the  validation  summary 

(ACVC)  report. 

Ada  An  Ada  compiler  with  its  host  computer  system  and  its 

Implementation  target  computer  system. 

Ada  Joint  The  part  of  the  certification  body  which  provides  policy  and 
Program  guidance  for  the  Ada  certification  system. 

Office  (AJPO) 

Ada  The  part  of  the  certification  body  which  carries  out  the 

Validation  procedures  required  to  establish  the  compliance  of  an  Ada 
Facility  (AVF)  inplementation. 

Ada  The  part  of  the  certification  body  that  provides  technical 

Validation  guidance  for  operations  of  the  Ada  certification  system. 

Organization 
(AVO) 

Compliance  of  The  eibility  of  the  implementation  to  pass  an  ACVC  version, 
cin  Ada 

Implementation 

Computer  A  functional  unit,  consisting  of  one  or  more  computers  and 

System  associated  software,  that  uses  common  storage  for  all  or  part 

of  a  program  and  also  for  all  or  part  of  the  data  necessary 
for  the  execution  of  the  program;  executes  user-written  or 
user-designated  programs;  performs  user-designated  data 

manipulation,  including  arithmetic  operations  and  logic 
operations;  and  that  can  execute  programs  that  modify 
themselves  during  execution.  A  computer  system  may  be  a 
stand-alone  unit  or  may  consist  of  several  inter-connected 
units. 
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Conformity 


Customer 


Declaration  of 
Conformance 


Host  Corrputer 
System 

Inapplicable 

test 

ISO 

LRM 


Operating 

System 


Target 

Computer 

System 

Validated  Ada 
Compiler 

Validated  Ada 
Implementation 

Validation 


Withdrawn 

test 


Fulfillment  by  a  product,  process,  or  service  of  all 
requirements  specified. 

An  individual  or  corporate  entity  who  enters  into  an  agreement 
with  an  AVF  which  specifies  the  terms  and  conditions  for  AVF 
services  (of  einy  kind)  to  be  performed. 

A  formal  statement  from  a  customer  assuring  that  conformity 
is  realized  or  attainable  on  the  Ada  implementation  for  which 
validation  status  is  realized. 

A  computer  system  where  Ada  source  programs  are  transformed 
into  executable  form. 

A  test  that  contains  one  or  more  test  objectives  found  to  be 
irreleveint  for  the  given  Ada  inplementation. 

International  Organization  for  Standardization. 

The  Ada  standard,  or  Language  Reference  Manual,  published  as 
ANSI/MIL-STD-1815A-1983  and  ISO  8652-1987.  Citations  from  the 
LRM  take  the  form  ''<section>.<subsection>:<paragraph>." 

Software  that  controls  the  execution  of  programs  euad  that 
provides  services  such  as  resource  allocation,  scheduling, 
input/output  control,  and  data  nanagement.  Usually,  operating 
systems  are  predominantly  software,  but  partial  or  complete 
hardware  inplementations  are  possible. 

A  coitputer  system  where  the  executable  form  of  Ada  programs 
are  executed. 


The  compiler  of  a  validated  Ada  implementation. 


An  Ada  implementation  that  has  been  validated  successfully 
either  by  AVF  testing  or  by  registration  [Pro92]. 

The  process  of  checking  the  conformity  of  an  Ada  conpiler  to 
the  Ada  programming  language  and  of  issuing  a  certificate  for 
this  inplementation. 

A  test  fo\ind  to  be  incorrect  and  not  used  in  conformity 
testing.  A  test  may  be  incorrect  because  it  has  an  invalid 
test  objective,  fails  to  meet  its  test  objective,  or  contains 
erroneous  or  illegal  use  of  the  Ada  programming  language. 


1-4 


C3iAPTEK  2 


IMPLEMENTATIOI  DEPENDENCIES 


2.1  WITHDRAWN  TESTS 

The  following  tests  have  been  withdrawn  by  the  AVO.  The  rationale  for 
withdrawing  each  test  is  available  from  either  the  AVO  or  the  AVF.  The 
publication  date  for  this  list  of  withdrawn  tests  is  22  November  1993. 


B27005A 

E28005C 

B28006C 

C32203A 

C34006D 

C35507K 

C35507L 

C35507N 

C35507O 

C35507P 

C35508I 

C35508J 

C35508M 

C35508N 

C35702A 

C35702B 

C37310A 

B41308B 

C43004A 

C45114A 

C45346A 

C45612A 

C45612B 

C45612C 

C45651A 

C46022A 

B49008A 

B49008B 

A54B02A 

C55B06A 

A74006A 

C74308A 

B83022B 

B83022H 

B83025B 

B83025D 

C83026A 

B83026B 

C83041A 

B85001L 

C86001F 

C9402LA 

C97116A 

C98003B 

BA2011A 

CB7001A 

CB7001B 

CB7004A 

CC1223A 

BC1226A 

CC1226B 

BC3009B 

BD1B02B 

BD1B06A 

AD1B08A 

BD2A02A 

CD2A21E 

CD2A23E 

CD2A32A 

CD2A41A 

CD2A41E 

CD2A87A 

CD2B15C 

BD3006A 

BD4008A 

CD4022A 

CD4022D 

CD4024B 

CD4024C 

CD4024D 

CD4031A 

CD4051D 

CD5111A 

CD7004C 

ED7005D 

CD7005E 

AD7006A 

CD7006E 

AD7201A 

AD7201E 

CD7204B 

AD7206A 

BD8002A 

BD8004C 

CD9005A 

CD9005B 

CDA201E 

CE2107I 

CE2117A 

CE2117B 

CE2119B 

CE2205B 

CE2405A 

CE3111C 

CE3116A 

CE3118A 

CE3411B 

CE3412B 

CE3607B 

CE3607C 

CE3607D 

CE3812A 

CE3814A 

CE3902B 

2.2  INAPPLICABLE  TESTS 

A  test  is  inapplicable  if  it  contains  test  objectives  vrtiich  are  irrelevant 
for  a  given  Ada  implen«ntation.  Reasons  for  a  test's  inapplicability  may  be 
supported  by  documents  issued  by  the  ISO  and  the  AJPO  known  as  Ada 
Commentaries  and  commonly  referenced  in  the  format  Al-ddddd.  For  this 
implementation,  the  following  tests  were  determined  to  be  inapplicable  for 
the  reasons  indicated;  references  to  Ada  Commentaries  are  included  as 
appropriate. 
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'iTie  following  201  tests  have  floating-point  type  declarations  requiring 
more  digits  than  SYSTEM. MAX  DIGITS: 


C24113L..Y  (14  tests) 
C35706L..Y  (14  tests) 
C35708L..Y  (14  tests) 
C45241L..Y  (14  tests) 
C45421L..Y  (14  tests) 
C45524L. .Z  (15  tests) 
C45641L..Y  (14  tests) 


C35705L..Y  (14  tests) 
C35707L..Y  (14  tests) 
C35802L..2  (15  tests) 
C45321L..Y  (14  tests) 
C45521L..Z  (15  tests) 
C45621L..Z  (15  tests) 
C46012L..Z  (15  tests) 


The  following  21  tests  checK  fo-"  the  predefined  type  SHORT_INTEGER;  for 
this  implementation,  there  i.s  no  such  type: 


C35404B 

C45412B 

C45611B 

B52004E 

CD7101E 


B36105C 

C45502B 

C45613B 

C55B07B 


C45231B 

C45503B 

C45614B 

B55B09D 


C45304B 

C45504B 

C45631B 

B86001V 


C45411B 

C45504E 

C45632B 

C86006D 


The  following  20  tests  check  for  the  predefined  type  LaNG_INTEGER;  for 
this  inplementation,  there  is  no  such  type: 


C35404C 

C45502C 

C45613C 

C55B07A 


C45231C 

C45503C 

C45614C 

B55B09C 


C45304C 

C45504C 

C45631C 

B86001W 


C45411C 

C45504F 

C45632C 

C86006C 


C45412C 

C45611C 

B52004D 

CD7101F 


C35404D,  C45231D,  B86001X,  C86006E,  eind  CD7101G  check  for  a  predefined 
integer  type  with  a  name  other  than  INTEGEa^,  LONG_INTEGER ,  or 
SHORT  INTEGER;  for  this  inplementation,  there  is  no  such  type. 


C35713B,  C45423B,  B86001T,  cind  C86006H  check  for  the  predefined  type 

SHORT_FLOAT;  for  this  implementation,  there  is  no  such  type. 


C35713D  and  B86001Z  check  for  a  predefined  floating-point  type  with  a 
name  other  than  FLOAT,  La4G_FLQAT,  or  SHORT_FLQAT;  for  this 
implementation,  there  is  no  such  type. 

C45531M..P  and  C45532M..P  (8  tests)  check  fixed-point  operations  for 
^ ypes  that  require  a  SYSTEM. MAX_MANTISSA  of  47  or  greater;  for  this 
inplementation,  MAX_MANTISSA  is  less  than  47. 

C45624A..B  (2  tests)  check  that  the  proper  exception  is  raised  if 
MACHINEjOVERFLOWS  is  FALSE  for  floating  point  types  and  the  results  of 
various  floating-point  operations  lie  outsiue  the  range  of  the  base 
type;  for  this  implementation,  MACHINE_OVERFLCWS  is  TRUE. 


B86001Y  uses  the  name  of  a  predefined  fixed-point  type  other  than  type 
DURATION;  for  this  implementation,  there  is  no  such  type. 
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C96005B  uses  values  of  type  DURATION'S  base  type  thac  are  outside  the 
remqe  of  type  DURATION;  for  this  inplementation,  the  ranges  are  the 
same. 


LA3004A. -B,  EA3004C. .D,  cind  CA3004E..F  (6  tests)  check  pragma  UNLINK  for 
procedures  and  functions;  this  implementation  does  not  support  pragma 
INLINE. 


CD1009C  checks  vhether  a  length  clause  Ccin  specify  a  non-default  size 
for  a  floating-point  type;  this  implementation  does  not  support  such 
sizes. 

CD2A84A,  CD2A84E,  CD2A84I..J  (2  tests),  eind  CD2A840  use  length  clauses 
to  specify  non-default  sizes  for  access  types;  this  implementation  does 
not  support  such  sizes. 

CD2B15B  checks  that  STORAGE  ERROR  is  raised  when  tl.e  storage  size 
specified  for  a  collection  Ts  too  small  to  hold  a  single  value  of  the 
designated  ype;  this  implementation  allocates  more  space  than  was 
specified  by  the  length  clause,  as  allowed  by  AI-00558. 

BD8001A,  BD8003A,  BD8004A. .B  (2  tests),  and  AD8011A  use  machine  code 
insertions;  this  implementation  provides  no  package  MACHINE_CODE . 

AE2101H,  EE2401D,  and  EE2401G  use  instantiations  of  package  DIRECT_lO 
with  unconstrained  arrav  types  and  record  types  with  discriminants 
without  defaults;  these  in/tantiations  are  rejected  by  this  compiler. 

The  tests  listed  in  the  following  table  check  that  USE  ERROR  is  raised 
if  the  given  file  operations  are  not  supported  for  the  given  combination 
of  mode  and  access  method;  this  implementation  supports  these 
operations. 

Test  File  Operation  Mode  File  Access  Method 


CE2102D 

CREATE 

IN  FILE 

SEQUENTIAL  10 

CE2102E 

CREATE 

OUT  FILE 

SEQUENTIAL  10 

CE2102F 

CREATE 

INOUT  FILE 

DIRECT  10 

CE2102I 

CREATE 

IN  FILE 

DIRECT  10 

CE2102J 

CREATE 

OUT  FILE 

DIRECT  10 

CE2102N 

OPEN 

IN  FILE 

SEQUENTIAL  10 

CE2102O 

RESET 

IN  FILE 

SEQUENTIAL  10 

CE2102P 

OPEN 

OUT  FILE 

SEQUENTIAL  10 

CE2102Q 

RESET 

OUT  FILE 

SEQUENTIAL  10 

CE2102R 

OPEN 

INOUT  FILE 

DIRECT  10 

CE2102S 

RESET 

INOUT  FILE 

DTRECT  10 

CE2102T 

OPEN 

IN  FILE 

DIRECT  10 

CE2102U 

RESET 

IN  FILE 

DIRECT  10 

CE2102V 

OPEN 

OUT  FILE 

DIRECT  10 

CE2102W 

"ESET 

OUT  FILE 

DIRECT  10 

CE2102E 

CREATE 

IN  FILE 

TEXT  10 

CE3102F 

CE3102G 

RESET 

DELETE 

Any  Mode 

TEXT_IO 

TEXT_IO 
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IMPLEMENTATICW  DEPENDENCIES 


CE3102I  CREATE  OUT_FILE  TEXT_10 
CE3102J  OPEN  IN_FILE  TEXT_IO 
CE3102K  OPEN  OUT_FILE  TEXT_IO. 

CE2203A  checks  that  WRITE  raises  USE_ERROR  if  Uie  capacity  of  an 
external  sequential  file  is  exceeded;  this  implementation  cauuiot 
restrict  file  capacity. 

CE2403A  checks  that  WRITE  raises  USE_ERROR  if  the  capacity  of  an 
external  direct  file  is  exceeded;  this  implementation  cannot  restrict 
file  capacity. 

CE3111B,  CE3111D..E  (2  tests),  CE3114B,  and  CE3115A  check  operations  on 
text  files  when  multiple  internal  files  are  associated  with  the  seune 
external  file  and  one  or  more  are  open  for  writing;  USE_ERROR  is  raised 
vdien  this  association  is  attempted. 

CE3304A  checks  that  SET_LINE^LENGTH  and  SET  PAGE_LENGTH  raise  USE_ERROR 
if  they  specify  an  inapproprTate  value  for  Bie  external  file;  there  are 
no  inappropriate  values  for  this  implementation. 

CE3413B  checks  that  PAGE  raises  LAYCXn'_ERROR  when  the  value  of  the  page 
number  exceeds  COUNT'LAST;  for  this  implementation,  the  value  of 
COUNT'LAST  is  greater  than  150000,  making  the  checking  of  this  objective 
inpractical. 


2.3  TEST  MODIFICATiaiS 

Modifications  (see  section  1.3)  were  required  for  122  tests. 

The  following  tests  were  split  into  two  or  more  tests  because  this 
implementation  did  not  report  the  violations  of  the  Ada  Standard  in  the  way 
expected  by  the  original  tests. 


B22003A 

B22003B 

B22004A 

B22004B 

B22004C 

B22005K 

B22005L 

B23002A 

B23004A 

B23004B 

B2400LA 

B24001B 

B24001C 

B24005A 

B24005B 

B24007A 

B24009A 

B24104A 

B242  )4A 

B24204B 

B24204C 

B24204D 

B24204E 

B24204F 

B24205A 

B24206A 

B242C6B 

B25002A 

B25002B 

B26001A 

B26002A 

B26005A 

B28003A 

B28003C 

B2900LA 

B2A003A 

B2A003B 

B2A003C 

B2A003D 

B2A003E 

B2A003F 

B2A004A 

B2A005A 

B2A005B 

B2A007A 

B2A021A 

B32103A 

B33101A 

B33201B 

B33202B 

B33203B 

B33301A 

B33301B 

B35101A 

B36002A 

B37106A 

B37205A 

B37307B 

B38003A 

B38003B 

B38009A 

B38009B 

B38103A 

B38103B 

B38103C 

B38103D 

B38103E 

B4120LA 

B44001A 

B44004A 

B44004B 

B44004C 

B45205A 

B48002A 

B48002D 

B51001A 

B53003A 

B55A01A 

B61005A 

B64006A 

B67001A 

B67001B 

B67001C 

B67001D 

B67001H 

B71001A 

B71001G 

B71001M 

B74104A 

B74307B 

B83E01C 

B83E01D 

B85008G 

B85008H 

B91001H 

B95001D 

B95003A 

B95004A 

B95063A 

BAllOlE 

BB1006B 

BB3005A 

BC1013A 

BC1109A 

BC1109B 

BC1109C 

BC1109D 

BC1201A 

BC1206A 

BC1303F 

BC2001D 

BC2001E 

BC3003B 

BC3005B 
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IMPLEMENTATION  DEPENDENCIES 


BC3013A  BD2B14A  BD2C14A  BE2210A  BE2413A 

BC3204D  and  BC3205C  were  graded  passed  by  Evaluation  Modification  as  directed 
by  the  AVO.  These  tests  are  expected  to  produce  conpilation  errors,  but  this 
implementation  compiles  the  units  without  error;  all  errors  are  detected  at 
link  time.  This  benavior  is  allowed  by  AI-00256,  as  the  units  are  illegal 
only  with  respect  to  units  that  they  do  not  depend  on. 

CE3804H  was  graded  passed  by  EvaJ’oation  Modification  as  directed  by  the  AVO. 
This  test  requires  that  the  string  "-3.525"  can  be  read  from  a  file  using 
FLOAT_lO  and  that  ein  equality  comparison  with  the  numeric  literal  '-3.525' 
will  evaluate  to  TRUE;  however,  because  -3.525  is  not  a  model  number,  this 
conparison  may  evaluate  to  FALSE  (LRM  4.9:12).  This  implementation's 
compile-time  and  run-time  evaluation  algorithms  differ;  thus,  this  check  for 
equality  fails  and  Report. Failed  is  called  at  line  81,  which  outputs  the 
message  "WIDTH  CHARACTERS  NOT  READ."  All  other  checks  were  passed. 
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CHAPTER  3 


PROCESSING  INFORMATION 


3.1  TESTING  ENVIRONMENT 

The  Ada  implemenLation  tested  in  this  validation  effort  is  described 
adequately  by  the  information  given  in  the  initial  cages  of  this  report. 

For  technical  and  sales  information  about  this  Ada  inqplementation,  contact: 

Jerry  Rudisin 

Rational  Software  Corporation 
2800  San  Tomas  Expressway 
Santa  Clara  CA  95051-0951 
(408)  496-3712 


Testing  of  this  Ada  inpleinentation  was  conducted  at  the  customer's  site  by  a 
validation  team  from  the  AVF. 


3.2  SUMMARY  OF  TEST  RESULTS 

An  Ada  Iirpleroentation  passes  a  given  ACVC  version  if  it  processes  each  test 
of  the  customized  test  suite  in  accordance  with  the  Ada  Programming  Language 
Stzuidard,  whether  the  test  is  applicedale  or  inapplicedile;  otherwise,  the  Ada 
Iirplementation  fails  the  ACVC  (Pro92). 

For  all  processed  tests  (inapplicable  and  applicable),  a  result  was  obtained 
that  conforms  to  the  Ada  Programming  Language  Standard. 

The  list  of  items  below  gives  the  number  of  ACVC  tests  in  various  categories. 
All  tests  were  processed,  except  those  that  were  withdrawn  because  of  test 
errors  (item  L;  see  section  2.1),  those  that  require  a  floating-point 
precision  that  exceeds  the  implementation's  maximum  precision  (item  e;  see 
section  2.2),  and  those  that  depend  on  the  support  of  a  file  system  —  if 
none  is  supported  (item  d).  All  tests  passed,  except  those  that  are  listed 
in  sections  2.1  and  2.2  (counted  in  items  b  and  f,  below). 
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PROCESSING  INFORMATIW 


a)  Total  Number  of  ^ipliceible  Tests 

b)  Total  Number  of  Withdrawn  Tests 

c)  Processed  Inapplicable  Tests 

d)  Non-Processed  I/O  Tests 

e)  Non-Processed  Floating-Point 

Precision  Tests 

f)  Total  Number  of  Inapplicable  Tests 

g)  Total  Number  of  Tests  for  ACVC  1.11 


3750 

104 

115 

0 

201 

316 

(C4d+e) 

4170 

(a+b+f ) 

3.3  TEST  EXECUnOJ 

A  magnetic  tape  containing  the  custcMized  test  suite  (see  section  1.3)  was 
taken  on-site  by  the  validation  team  for  processing.  The  validation  tape  was 
loaded  on  a  machine  acting  as  a  file  server.  The  files  were  accessed  via 
automounted  NFS. 


After  the  test  files  were  loaded  onto  the  host  computer,  the  full  set  of 
tests  was  processed  by  the  Ada  implementation. 

The  tests  were  compiled,  linked  and  executed  on  the  host  computer  system. 
The  results  were  captured  on  the  host  computer  system. 

Testing  was  performed  using  command  scripts  provided  by  the  customer  and 
reviewed  by  the  validation  team.  See  Appendix  B  for  a  complete  listing  of 
the  processing  options  for  this  implementation.  It  also  indicates  the 
default  options.  The  options  invoked  explicitly  for  validation  testing 
during  this  test  were: 


Option  I  Switch  Effect 


-listing_directory  <dir>  To  produce  a  listing  in  the  specified 

directory  <dir>. 


-compile  To  syntactically  and  semantically  analyze  a 

source  file  and  produce  an  Ada  unit  (or 
units)  if  correct. 


-goal  linked 


Produce  the  object  code  emd  linked 
executedsle  for  an  Ada  main  program. 


Test  output,  compiler  and  linker  listings,  and  job  logs  were  captured  on 
magnetic  tape  and  archived  at  the  AVF.  The  listings  examined  on-site  by  the 
validation  team  were  also  archived. 
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APPENDIX  C 


APPENDIX  F  OF  THE  Ada  STANDARD 


The  only  allowed  implementation  dependencies  correspond  to 
in^lementat ion-dependent  pragmas,  to  certain  machine-dependent  conventions  as 
mentioned  in  Chapter  13  of  the  Ada  Standard,  and  to  certain  allowed 
restrictions  on  representation  clauses.  The  iirplementation-dependent 
characteristics  of  this  Ada  implementation,  as  described  in  this  ^^pendix, 
are  provided  by  the  customer.  Unless  specifically  noted  otherwise, 
references  in  this  Appendix  are  to  compiler  documentation  and  not  to  this 
report.  Implementation-specific  portions  of  the  package  STANDARD,  v^iich  are 
not  a  part  of  ^pendix  F,  are: 


package  STANDARD  is 

!:ype  Integer  is  range  -2147483648  ..  2147483647; 

type  Float  is  digits  6 

range  -3.40282E+38  ..  3.40282E+38; 

type  Long  Float  is  digits  15 

range  -1.79769313486231E+308  ..  1.79769313486231E+308; 

type  Duration  is  delta  0.000061035156 

range  -131072.00000000  ..  131071.9999389648437500000000; 

end  STANDARD; 
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This  chapter  provides  information  as  required  by  the  LRM 
Appendix  F.  The  Implementation-dependent  characteristics  of 
Rational  Ada  are  described  in  the  following  sections: 

■  “Pragmas'  on  page  79 

■  “Attributes"  on  page  101 

■  “Packages  Standard  and  System"  on  page  105 

■  “Representation  Clauses"  on  page  108 

■  "Implementation-Generated  Names*  on  page  110 

■  ‘Address  Clauses  (LRM  13.5)’  on  page  111 

■  “Unchecked  Programming"  on  page  111 

■  “Input /Output  Packages"  on  page  112 

■  “Other  Implementatlon-Oependent  Features"  on  page  114 

Pragmas 


This  section  provides: 

■  General  notes  about  pragma  error  handling 

■  A  table  of  implementation  dependencies  In  the  predefined 
pragmas  fi-om  LRM  Annex  B 

■  A  table  of  implementation-defined  pragmas 

■  Detailed  descriptions  of  each  of  the  implementation-defined 
pragmas  starting  on  page  83 

Error  Handling  for  Pragmas 

A  pragma  whose  existence,  placement,  or  arguments  do  not 
correspond  to  those  allowed  is  Ignored,  by  default,  by  the 
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compiler  and  the  runtime  system.  This  means  that  a  warning 
Is  generated  If  the  compiler  detects  such  an  error,  but  In  any 
event  the  compilation  completes  successfully. 

Several  Apex  context  switches  allow  you.  however,  to  specify 
udiether  to  treat  certain  classes  of  Invalid  pragmas  as  errors 
that  prevent  successful  compilation  rather  than  as  warnings. 
See  Appendix  A.  ‘Switches."  for  details  on  the  following 
switches: 

■  ReJect_Bad_Lrm_Pragmas:  Affects  the  handling  of  llleg2d 
LRM-deflned  pragmas 

■  ReJect_Bad_Ratlonal_Pragmas:  Affects  the  handling  of 
Illegal  Rational  implementation-defined  pragmas 

■  Reject_Undefined_Pragmas:  Affects  the  handling  of 
pragmas  defined  neither  In  the  LRM  nor  In  this  Appendix  F 

If  more  than  one  of  the  same  pragma  Is  specified  where  It  Is  not 
appropriate  to  do  so  (for  example,  two  pragma  Mains  on  the 
same  unit),  the  first  one  Is  us^  and  the  others  generate 
warnings  at  compile  time. 

References 

■  pragma  warnings,  LRM  2.8(9).  2.8(  1 1 ) 

Predefined  Pragmas 

For  each  pragma  defined  in  Annex  B  of  the  LRM.  Table  10-1 
describes  the  extent  to  which  Rational  Ada  supports  it. 


Table  10-1  Predefined  Pragma*  from  LRM  Annex  B 


Predefined 

Pragma 

Level  of  Support 

Controlled 

Always  Implicitly  in  effect  because  the  implementa¬ 
tion  does  not  support  automatic  garbage  collection 

Elaborate 

As  described  in  Aimex  B 

Inline 

Has  no  effect 

Interface 

As  described  In  Annex  B;  must  be  used  In  conjunc¬ 
tion  with  pragmas  Import  Procedure  and  Import- 
Function 
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Teibla  10- J  Prmd^flnml  PragmoM  Jjvm  UUt  Annex  B  (Continued) 
Predefined 

Pragma  Level  of  Support  _ 

List  Aa  described  in  Annex  B 

Memoiy_Slze  Has  no  eflect 

Optimize  Has  an  eflect  only  when  located  In  the  outermost 

scope,  where  It  applies  to  the  entire  compilation  unit; 
if  not  used,  the  value  SPACE  is  assumed.  See  "Set¬ 
ting  the  Optimization  Objective”  on  page  2 1 

Pack  As  described  in  Annex  B:  see  “Concepts  for  Object 

Sizes’  on  page  67 

Page  As  described  in  Annex  B 

Priority  As  described  in  Annex  B  and  LRM  9.8(2):  the  default 

is  127 

Shared  As  given  in  Annex  B:  has  an  eflect  only  for  integer, 

enumeration,  access,  and  fixed  types 

Storage_Unlt  Has  no  eflect 

Suppress  As  described  in  Annex  B 

Sy8tem_Name  Has  no  eflect  (there  is  only  one  enumeration  literal  in 
the  type  System.System_Name) 

Impiementation-Defined  Pragmas 

Table  10-2  summarizes  ail  Implementation-defined  pragmas  in 
Rational  Ada.  Each  pragma  is  described  in  more  detail  in  the 
following  subsections. 
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Table  10-2  ImpIemeruotioR-Oe/lned  PragmoM 


Implementation- 
Defined  Pragma 

Description 

Amert 

Raiaes  an  exception  if  a  apeclfled  Boolean 
expression  evaluates  to  False  at  run  time 

CoUection_PoIicy 

Controls  memory  allocation  for  the  collec¬ 
tion  designated  by  an  access  type 

ExportFunctlon 

Creates  a  global  symbol  for  an  Ada  function 
so  that  it  can  be  called  by  non-Ada  code 

Export_ObJect 

Creates  a  global  symbol  for  an  Ada  obj<‘ct  so 
that  it  can  be  referenced  bv  non-Ada  code 

ExportProcedure 

Creates  a  global  symbol  for  an  Ada  proce¬ 
dure  so  that  It  can  be  called  by  non-Ada 
code 

Genertc_Poilcy 

Tells  the  compiler  how  to  generate  code  for  a 
generic  and  its  instantiations 

linport_Functlon 

Associates  the  global  symbol  for  a  non-Ada 
function  with  an  Ada  name  so  that  an  Ada 
subprogram  can  call  the  function 

Iniport_ObJect 

Associates  the  global  symbol  for  a  non-Ada 
object  with  an  Ada  name,  so  that  an  Ada 
subprogram  can  reference  the  object 

Import^Procedure 

Associates  the  global  symbol  for  a  non-Ada 
procedure  with  an  Ada  name,  so  that  an  Ada 
subprogram  can  call  the  procedure 

Initialize 

Specifies  that  default  initialization  be  car¬ 
ried  out  for  an  imported  object  or  an  object 
referenced  by  an  address  clause 

Instance_Pollcy 

Specifies  replicated  code  for  specific  instan¬ 
tiations  of  a  shared-code  generic 

Main 

Designates  eui  Ada  nuUn  unit  and  specifies 
aspects  of  its  run-time  behavior 

Must_Be_Conatralned 

Indicates  whether  formal  private  and  limited 
private  types  within  a  generic  formal  i>art 
must  be  constrained 
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Tablm  10'2  Implmmtation-D^nmd  Pragma*  (Continumd) 


Implementatlon- 
Deflmed  Pragma 

Deacilptlom 

Signal_Handler 

Installs  a  procedure  as  a  UNIX  signal 
handler 

SuppreasAll 

Suppresses  all  permitted  runtime  checks 

Suppresa_Elaboratlon- 

_Checka 

Suppresses  elaboration  checks  for  a  specific 
compilation  unit 

Pragma  Assert 

Raises  an  exception  If  a  specified  Boolean  expression  evaluates 
to  False  at  run  time.  The  syntax  is: 

pragma  ASSHRT 

([PREDICATE  •>]  booiaan_axpraaaion) ; 

Arguments 

■  Predicate:  The  Boolean  expression  to  be  evaluated  at  run 
time. 

Usage 

When  the  pragma  is  encountered  at  run  time,  the  Boolean 
expression  is  evaluated.  If  the  result  is  False,  the  System.Asser- 
tion_Error  exception  is  raised:  if  the  result  Is  True,  no  action  is 
taken. 

This  pragma  can  appear  anywhere  that  a  declaration  or  state¬ 
ment  is  allowed. 

Pragma  Collection_Policy 

Controls  memory  allocation  for  the  collection  designated  by  an 
access  type.  The  syntax  is: 

pragma  COLLECT  XOR_POZ.ZCT 
(ACCE8S_TTPB  » 

IEXTZAL_SIZE  •» 

( ,  EZTEB8IBLB  ■» 

[ ,  EZTEH8IOR_8IZE  •» 


Maem*m_typ», 
ia tmg*r_m*prmm*i ea 
bool *ma_*xpe*mmioa ] 
iatog*c_oxpr»m*ion] ) ; 
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Arguments 

u  Acceas_Typ«:  The  access  type  on  which  to  perform  storage 
management. 

■  Xaitlal_8lse:  The  size  In  storage  units  of  the  initial  collec¬ 
tion  that  Is  created  for  an  access  type.  A  negative  value  Is 
treated  as  0. 

■  Extenslbla:  Specifies  whether  the  collection  can  be 
extended.  If  True,  sets  the  extension  size  to  the  default  or 
specified  value  of  ExtensionJSlze:  otherwise.  Ehrteiislon_Sl2e 
is  ignored.  The  default  value  Is  True. 

■  Ezt«nsioxi_size:  The  minimum  nvimber  of  storage  units 
by  which  the  collection  will  be  extended,  when  needed.  If  It 
is  extensible.  A  negative  value  is  treated  as  0.  The  default 
value  is  4,096  bjrtes. 

Usage 

The  pragma  must  appear  in  the  same  declarative  region  as  the 
access  type  to  which  it  applies,  after  the  access  type's  declara¬ 
tion  and  before  any  forcing  occurrence  of  the  access  type.  If  the 
access  type  Is  a  private  type,  the  pragma  must  appear  in  the 
private  part  after  the  complete  access-type  declaration.  If  the 
pragma  appears  outside  the  specified  areas,  it  is  ignored. 

A  description  and  example  of  the  pragma's  application  are 
provided  in  '‘Managing  Storage  for  Access  Types"  on  page  63. 

Notes 

■  The  argumenis  must  be  specified  using  named  association. 

■  Only  one  Collectlon_Policy  pragma  is  allowed  per  access 
type.  If  more  than  one  is  specified,  the  first  if  applied  and 
the  rest  are  ignored. 

■  When  an  access  tyjje  has  an  associated  'Storage_Slze 
clause,  any  Collection_Policy  pragma  for  that  access  type  is 
ignored.  This  occurs  because  a  statement  of  the  form: 

for  Z' 8T011A0B_SXZE  uso  sir*; 
is  functionally  equivalent  to: 
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pragM  CQLLBCTZOB_POI.ICT 
(aCCB8S_TXPB  ->  Z, 

ZBZTZaL_8ZZB  -> 

BZT8a8ZBIJI  ->  PJOSB) ; 

■  If  InitlalJSlze  is  nonpositive  and  Extensible  is  False, 
attempting  to  execute  an  allocator  of  the  access  type  raises 
the  Storage_Error  exception. 

References 

■  access  type.  LRM  3.8 

■  allocator.  LRM  4.8 

■  collection.  LRM  3.8 

■  forcing  occurrence.  LRM  13.1(6) 

■  Storage_Error.  LRM  11.1 

■  Storage_Size.  LRM  13.7.2 

Pragmas  Export_Function,  Export_Ob]ect,  and  Export_Procedure 

Creates  a  global  symbol  for  an  Ada  subprogram  (function  or 
procedure)  or  object  so  that  it  can  be  called  or  referenced  by 
non-Ada  code.  The  syntax  is: 

pragM  BZPOM_PaHCTZ08 

([Z>TBRaAI.~  •>] 

(,  (BZTBRHAZ.  »] 

(,  [PARAMBTBR_TTFB8  ->] 

[,  IRBS0LT_TIPK  ■>] 

[,  [UUIOUAGB  ->] 


iBtarBai_aaaa 

"MtaraaJ.aaaa”] 

tYp*_mark] 
laagvagm_uamm] ) ; 


pragma  BZPORT_OBJBCT 

((IBTBIUIAI.  ->]  intaraaJ_flaM 

[ ,  (BZTBIUUa.->]  ''•rtaraal_JiaM'  ]  )  ; 

pragma  BZPORT_PROCBDUItB 


( [ ZBTBRHAL 

->1 

iatarDai_aama 

Ir 

(BZTBRBRL 

->1 

” •xterBai_nama” ] 

[ PARMIBTBR_TTPBS 

->) 

parmmmt*r_typm_limt] 

(UUIOUAOB 

->1 

langumg9_nmmm] ) f 
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Arguments 

m  Internal:  The  Ada  simple  name  of  the  Ada  subprogram  or 
object  to  be  exported.  For  functions.  thi«i  can  also  be  an 
operator  symbol. 

m  External:  An  optional  string  literal  that  specifies  the  global 
symbol  name  to  be  created  the  Ada  compiler.  This  name 
must  obey  the  naming  conventions  for  the  host  operating 
system’s  object-module  format,  and  therefore  it  may  differ 
from  the  internal  subprogram  or  object  name.  If  an  external 
name  is  not  specified,  the  internal  name  is  used  for  the 
symbol  name. 

■  Paraaatar_Typas:  A  parenthesized,  comma-separated  list 
of  type  and/or  subtype  names  that  describes  the  param¬ 
eter-type  profile  of  an  exported  subprogram.  If  the  subpro¬ 
gram  has  no  parameters,  the  list  can  consist  of  the  single 
word  Null.  This  optional  argument  may  be  required  when 
the  Internal  argument  specifies  an  overloaded  subprogram. 
See  “Usage."  below. 

■  Raault^Typa:  The  result-type  profile  of  an  exported 
function.  This  optional  argument  may  be  reqvilred  when  the 
Internal  argument  specifies  an  overloaded  function.  See 
“Usage."  below. 

■  Languags:  'The  name  of  the  language  In  which  the  calling 
code  is  written.  The  only  language  name  currently 
supported  is  C:  always  use  this  vadue  when  exporting  to  C 
or  €•»■+.  Other  language  names  are  Ignored,  so  this 
argument  can  be  omitted  when  exporting  to  a  language 
other  than  C  or  C++. 

Usage 

Use  these  export  pragmas  to  create  global  symbolic  names  for 
Ada  subprograms  that  will  be  called — or  Ada  objects  that  will  be 
referenced — ^from  non-Ada  code.  The  linker  will  use  these 
symbols  to  resolve  Intermodule  references. 

If  the  internal  subprogram  name  is  overloaded,  you  must 
supply  enough  information  for  the  compiler  to  determine 
unambiguously  which  subprogram  to  export.  Specify  the 
Parameter_'iypes  (and/or.  for  functions,  the  Result_'rype)  so 
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that  the  compiler  can  construct  the  parameter-  and/or  result- 
type  profile  of  the  subprogram. 


Cautions  Exporting  a  subprogram  does  not  export  the  mecha¬ 
nism  used  by  the  compiler  to  perform  elaboration  checks.  A  call 
from  another  language  to  an  exported  subprogram  with  an 
unelaborated  body  may  produce  unpredictable  results  when  the 
subprogram  references  an  object  that  is  itself  unelaborated. 


Caution:  Accesses  to  Ada  objects  by  non-Ada  code  are  inher¬ 
ently  unsafe;  the  compiler  and  runtime  system  cannot  guarantee 
the  integrity  of  such  exported  objects.  It  is  the  developer’s  respon¬ 
sibility  to  ensure  that  the  code  that  accesses  an  e:qx>rted  object 
property  Interprets  and  maintains  the  underlying  structure  of  the 
object. 


Notes 

a  An  export  The  pragma  can  appear  only  at  the  place  of  a 
declarative  item  in  a  declarative  part  or  package  specifica¬ 
tion;  the  subprogram  or  object  to  which  it  applies  must 
have  been  declared  by  an  earlier  declarative  item  of  the 
same  declarative  part  or  package  specification. 

m  An  exported  subprogram  must: 
a  Not  be  a  generic 

a  Be  declared  in  a  static  scope;  that  is.  it  must  not  be 
Inside  any  subprogram,  taisk.  generic  unit,  or  block 
statement 

m  An  exported  object  must: 

□  Not  be  in  a  generic  unit 
a  Be  a  variable 

Q  Be  declared  in  a  static  scope;  that  is.  it  must  not  be 
inside  any  subprogram,  task,  generic  unit,  or  block 
statement 

□  Have  a  static  size;  that  is.  Its  subtype  must  be  one  of: 

-  A  scalar  type  or  subtype 

-  An  array  subtjrpe  with  static  index  constraints  whose 
component  size  is  static 

-  An  undiscriminated  record  type  or  subtype 
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References  for  Subprograms 

■  elaboration  of  a  library  unit.  LRM  10.5 

■  order  of  elaboration.  LRM  3.9 

■  overloading.  LRM  8.3 

■  parameter  and  result  type  profile.  LRM  6.6 

■  “Calling  an  Ada  Subprogram  from  C"  on  page  6 

References  for  Objects 

■  limited  private  type.  LRM  7.4.4 

■  private  type,  LRM  7.4 

■  ‘Sharing  Global  Objects"  on  page  14 

Pragma  Generic_Policy 

Tells  the  compiler  how  to  generate  code  for  a  generic  package  or 

subprogram  and  its  instantiations.  The  syntax  is; 

pragma  OBSKRXC^POLZCT 

( [  OKnRZC_UHXT->  1  aiapia_aaaa, 

(CODS  »]  ltBn.ZCATBO  |  SBSItBD) } 

Arguments 

■  Gsaarlcjdnit:  The  simple  name  of  the  generic  package  or 
subprogram  to  which  the  pragma  applies. 

■  Coda:  A  keyword  that  specifies  whether  edl  instantiations 
should  share  the  code  in  one  common  routine  (Shared),  or 
whether  each  instantiation  should  be  coded  separately 
(Replicated). 

Usage 

See  “Setting  Shared  or  Replicated  Generic  Policy”  on  page  22. 

Notes 

■  Use  pragma  Instance_Policy  to  override  the  shared  Generic - 
_Pollcy  for  one  or  more  instantiations  of  a  generic  package 
or  subprogram.  See  "Pragma  Instance_Policy"  on  page  93. 

■  The  compiler  treats  all  generics  as  Replicated  unless  other¬ 
wise  specified  with  pragma  Generic_Pollcy. 
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m  The  pragma  can  appear  only  at  the  place  of  a  declarative 
Item  In  a  declarative  part  or  package  specification;  the 
generic  to  which  It  applies  must  have  teen  declared  by  an 
earlier  declarative  Item  of  the  same  declarative  part  or 
package  specification. 

■  Any  generics  appearing  In  Apex  interlace  views  must  be 
shared,  since  the  compiler  caimot  access  the  generic  body 
to  use  as  a  template  for  coding  replicated  instantiations. 

References 

■  generic  Instantiation.  LRM  12.3 

■  generic  package.  LRM  12.1 

a  generic  subprogram.  LRM  12.1 
m  simple  name.  LRM  4.1 

Pragmas  import_Function,  lmport_Ob]ect,  and  lmport_Procedure 

Associates  an  Ada  name  with  the  global  symbol  for  a  non-Ada 
subprogram  (function  or  procedure)  or  object  so  that  an  Ada 
subprogram  can  call  the  subprogram  or  reference  the  object. 
The  syntax  is: 

pragma  ZMPORT.PUHCTZOH 
((ZBTSiaiAL~ 

(,  (BZTB3UIAL 
( ,  [PAIUU«BTBR_TTPBS 
[,  [RBSULT_TTPB 
( ,  (MBCHAHZSM 

pragma  ZMPORT_OBJECT 

({ZRTBRRAL  >>]  iatarDai_oama 
[,  [KXTBRllAL->] 

pragma  Z}IPORT_PROCSDURB 

( ( ZRTBRBAZ.  «>] 

( ,  [BZTBRRAZ.  ->] 

[,  [PRRANBTBR_TXPB8  ->] 

( ,  [MBCHAHZSM  ->) 

Arguments 

■  Zntamal:  The  Ada  simple  name  of  the  non-Ada  subpro¬ 
gram  or  object  to  be  Imported. 


intaraai_aama 
"  •xt»rnmX_nmm»''  ] 

■achaaia«_Jiat] ) ; 


>>]  iataraai^oama 
>>  ]  ”  artaraai^aaM”  I 

■>1  paraaatar_t7pa_iiat] 
■>J  tjj>a_mar*] 

>>]  «aciiaaia«_Jiat] ) ; 
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■  Eztsrnal:  An  optional  string  literal  that  specifies  the  global 
s3anbol  name  to  be  created  by  the  Ada  compiler.  Since  other 
languages  may  enforce  non-Ada-compatible  naming  con¬ 
ventions.  the  external  symbol  may  differ  firom  the  internal 
subprogram  or  object  name.  If  an  external  name  is  not 
specifi^.  the  internal  name  is  used  for  the  symbol  name. 

a  ParaMt«r_T7p«s;  A  parenthesized,  comma-separated  list 
of  tJTJe  and/or  subtype  names  that  describes  the  param- 
eter-^^je  profile  of  an  Imported  subprogram.  If  the  subpro¬ 
gram  baa  no  parameters,  the  list  can  consist  of  the  single 
word  Null.  This  optional  argument  may  be  required  when 
the  Internal  argument  specifies  an  overloaded  subprogram. 
See  “Usage."  below. 

■  Rasult^Type:  The  result-type  profile  of  an  imported 
function.  This  optional  argument  may  be  required  when  the 
Internal  argument  specifies  an  overloaded  function.  See 
“Notes."  below. 

■  Mschanissi:  A  parenthesized,  comma-separated  list  of 
parameter -passing  mechanisms  for  the  parameters  passed 
by  a  subprogram.  If  the  Imported  subprogram  has  parame¬ 
ters.  then  the  Mechanism  argument  is  required:  otherwise, 
do  not  include  Mechanism.  There  must  be  a  one-to-one 
correspondence  between  the  passed  parameters  and  the 
mechanisms.  The  supported  mechanisms  are: 

□  Value:  The  corresponding  parameter  is  passed  by  value. 

Note:  When  Intetfaclng  with  C  or  C++,  only  scalars  can  be 
passed  by  value;  Mechanism  must  always  be  Value  and 
the  corresponding  Ada  parameter  must  beanin  parameter 
Jor  scalars. 

□  Reference:  The  corresponding  parameter  is  passed  by 
reference:  that  is.  its  address  is  passed.  This  applies  to 
records  zuid  arrays  in  C  and  C++  and  to  C++  constant 
reference  parameters. 

If  all  of  the  imported  subprogram's  parameters  are  passed 
with  the  same  mechanism,  you  can  specify  a  single  occur¬ 
rence  of  the  mechanism  without  parentheses. 


90 


7x9*  Printed  Template,  rev.  1.9 


Pragmas:  Pragmas  lmport_Functlon,  Import^ObJect,  and  lmport_Procedure 


Usage 

Use  the  Import  pragmas  to  supply  more  toformatloii  about  a 
non-Ada  subprogram  specified  with  pragma  Interface  or  a  non- 
Ada  object  to  be  referenced  by  Ada  cixle. 

Every  Imported  subprogram  must  be  described  both  ly  pragma 
Interface  and  by  an  Import  pragma,  in  that  order.  Pragma  Inter¬ 
face  is  Ignored  if  there  is  no  corresponding  import  pragma,  or  if 
the  import  pragma  contains  errors. 

If  the  internal  Ada  subprogram  name  is  overloaded,  you  must 
supply  enough  information  for  the  compiler  to  determine 
unambiguously  which  subprogram  is  being  Imported.  Specify 
the  Parameter  Types  (and/or.  for  functions,  the  Result  Type) 
so  that  the  compiler  can  construct  the  parameter-  and/or 
result-type  pro^e  of  ♦he  subprogram. 

A  Caution:  Accesses  to  non-Ada  objects  from  Ada  code  are  Inher¬ 
ently  unsafe:  the  compiler  and  runtime  system  cannot  guarantee 
the  Integrity  of  such  Imported  objects.  It  Is  the  developer's  re¬ 
sponsibility  to  ensure  that  the  code  that  accesses  an  Imported  ob¬ 
ject  properly  interprets  and  maintains  the  underlying  structure  of 
the  object. 

Notes 

■  An  import  The  pragma  can  appea''  onfy  at  the  place  of  a 
declarative  item  in  a  declarative  part  or  package  specifica¬ 
tion;  the  subprogram  or  object  to  which  it  applies  must 
have  been  declared  by  an  earlier  declarative  item  of  the 
same  declarative  part  or  package  specification. 

■  An  import  pragma  must  not  refer  to  a  genci^c  subprogram. 
■  An  Imported  object  must; 

□  Not  be  in  a  generic  unit 

□  Be  a  variable  declared  at  the  outermost  level  of  a  library- 
package  specification  or  body 

□  Have  a  static  size;  that  is,  its  subtype  must  be  one  of; 

-  A  scalar  type  or  subtype 

-  An  array  subtype  with  static  index  constraints  whose 
component  size  is  static 

-  An  undiscriminated  record  type  or  subtype 
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■  To  assign  an  imported  object  a  de&ult  initial  value,  use 
pragma  Initialize.  See  ‘Pragma  Initialize'  on  page  92. 

References  for  Subprograms 

■  interlace  to  other  languages.  LRM  13.9 

■  pragma  Interlace.  LRM  13.9 

■  scalar  types.  LRM  3.3 

■  ‘Calling  a  Non-Ada  Subprogram  from  Ada"  on  page  6 

References  for  Objects 

■  limited  private  type.  LRM  7.4.4 

■  private  type.  LRM  7.4 

■  ‘Sharing  Global  Objects  *  on  page  14 

Pragma  Initialize 

Specifies  that  default  initialization  be  CEirried  out  for  an 
imported  va..-lable  or  a  variable  referenced  by  an  address  clause. 
The  syntax  is: 

prsgns  ZSZTZALZZB 
( siapi ) ; 

Arguments 

■  Bimplm_naam:  The  variable  to  which  default  initialization  is 
to  be  applied. 

Usage 

When  a  program  imports  a  variable  object  or  declmes  a  variable 
with  an  address  clause,  the  compiler  assumes  that  this  variable 
previously  existed.  The  compiler  makes  no  attempt  to  assign  a 
default  (initial)  value  to  this  variable,  because  the  variable 
might  already  contain  a  valid  value  or  might  be  given  an  initial 
value  by  some  other  program.  By  default,  the  compiler  does  not 
perform  any  initialization  on: 

■  Variables  designated  by  addre-ss  clauses 

■  Imported  variable  objects:  see  ‘Pragmas  Import  Function. 
Import  Object.  and  Import  Procedure”  on  page  89 
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Pragma  Initialize  tells  the  compiler  to  assign  an  appropriate 
deiault  value  to  the  variable — for  example,  setting  pointers  and 
pointer  fields  to  null,  record  fields  to  the  initial  values  present 
in  the  record  type  definition,  and  discriminants  to  their  proper 
values.  Hence,  the  variable  must  not  have  eui  explicit  Initial 
value. 

No  additional  storage  space  is  allocated  because  valid  variables 
already  exist. 

The  referenced  variable  must: 

m  Have  been  declared  earlier  in  the  same  declarative  part 
m  Be  an  array  or  record 

■  Have  an  associated  address  clause,  or  it  must  have  been 
imported  using  pragma  Import  ObJect  before  the  occur¬ 
rence  of  pragma  Initialize 

■  Not  have  an  explicit  initial  value 

Example 

Pragma  Initialize  can  be  used  to  request  that  pointers  be  set  to 
Null  or  that  record  fields  be  given  some  starting  value. 

References 

■  address  clause.  LRM  13.5 

■  default  initialization.  LRM  3.2.1 

Pragma  lnstance_Policy 

Specifies  how  to  generate  code  for  specific  instantiations  of  a 
generic.  The  S3aitax  is; 

pragaa  zaSTAHCB_POLZCT 
( [ IHSTAKTZATIOH  ->] 

(COOB  ->)  RBPLZCATBD  |  SBABBD) ; 

Arguments 

■  Znstantiation:  The  simple  name  of  the  specific  instantia¬ 
tion  to  which  the  pragma  applies. 

■  Coda:  A  ke5rword  whose  value  can  be  Replicated  or  Shared. 
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Usage 

Use  pragma  Instance_Pollcy  to  specify  whether  to  generate 
replicated  or  shared  code  for  specific  Instantiations  of  generics. 

The  following  example  Illustrates  the  use  of  the  pragma: 

—  ■ZCH1UI0B_X  sad  KXCBJUIOB_R  us*  th*  coonon  sbsr*d 

—  cod*.  BZCBABOB_S  us*a  its  own  rspliestsd  cod*. 


g*a*rle 

typ*  Soaatyps  is  privstsi 
proeadurs  8mp(Z,  Ti  in  out  Soastyp*); 
pragma  0*nsrie_Pol icy (Swap,  Sharsd)) 

preesdurs  B«changs_R  is  nmw  Si#ap(Soa*typ*  >>  R*sl); 
proccdur*  Bxebangs_I  is  n*w  8wap(Somstyps  ■•>  Intsgsr); 
subtyps  S  is  String(l. .100) } 

proeadurs  Bsebang*_8  is  n*%r  Swap(Somatyp*  ->  S); 
pragma  Znstane*_Poliey (Rzebang*_S,  Raplieatad); 

Notes 

■  The  pragma  Is  Ignored  If  the  Instantiation  refers  to  a  generic 
In  an  Apex  interlace  view. 

■  The  pragma  and  the  named  Instantiation  must  occur  within 
the  same  declarative  part  or  package  specification. 

■  The  instantiation  must  occur  before  the  pragma. 

■  If  the  Instantiation  argument  refers  to  several  preceding 
overloaded  subprogram  instantiations,  the  pragma  applies 
to  all  of  them. 

■  Only  one  pragma  Instance  Policy  can  be  applied  to  each 
instantiation. 

References 

■  “Pragma  Generic  Pollcy"  on  page  88 

■  “Setting  Shared  or  Replicated  Generic  Policy"  on  page  22 

■  generic  instantiation.  LRM  12.3 

■  generic  package.  LRM  12.1 

■  generic  subprogreun.  LRM  12.1 

■  simple  name.  LRM  4.1 
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Pragma  Main 


Designates  an  Ada  main  unit  and  determines  some  aspects  of 
Its  runtime  behavior.  The  syntax  Is: 


prsgas  lUia 

[  ([OBTBCT.OBIOLOCK  » 

[HBaP_SX»  «> 

(>a>BL0CKlM0_lO  -> 

(POSIZ_COMPLZAn  -> 

[PIUIBIPTXVB_SCBSIxn.ZBO  -> 
[szoaAL_8Tju:x_8iza  -> 
[aTxac_8zzB  -> 

tTA8K_PRI0RZTT_DKPXUI.T  -> 
tTA8K_8TACK_SIZB_DKPAULT 

-> 

[TZMR_8LZCR  -> 


boolm*tt_*xpr*mmioa, ] 
mtmtic_iatmgar_mxprmmmioa, ] 
booJ.ama_mxprmmmiea,  ] 
boolaaa_axprmmmioa, ] 
boolaaa_axprmmaioa, ] 
mtatie_iatmgar_axprmmmioa,  ] 
mtMtie_iatagar_mxpramMioa, ] 
priority_axprmmmioa , ] 

mtatia_iatmgar_mxprammioB,  ] 
durmtioa_axprammioa\)  ]; 


Arguments 

■  D«tact_Oaadlock:  Specifies  v^rhether  the  Rational  Ada 
runtime  system  should  diagnose  deadlock  situations  in  the 
program.  If  True,  the  runtime  system  will  print  a  diagnosis 
of  what  Is  causing  the  tasks  to  block  when  deadlock  occurs. 
If  False,  the  program  simply  hangs.  The  deihult  Is  False. 

■  Hsap_slze:  A  noimegattve  static  integer  expression  that 
specifies  how  much  apace  to  allocate  for  the  heap,  in  bytes, 
when  the  main  unit  begins  execution.  If  this  argument  is 
specified,  no  additional  space  is  allocated  to  the  heap  after 
Initialization;  requests  for  more  heap  space  raise  Storage - 
_Error. 

If  not  specified,  heap  space  Is  allocated  dynamically  as 
needed  until  space  Is  exhausted  and  Storage_Error  Is 
raised. 

■  Nonblocklng_Io;  Specifies  whether  I/O  should  block  all 
tasks  in  the  program.  If  True,  only  the  task  performing  the 
I/O  blocks;  If  False,  the  entire  program  blocks.  For  a 
description  of  limitations  and  operation,  see  ‘I/O  In  Tasking 
Programs'  on  page  34  and  ‘Using  Blocking  and 
Nonblocking  I/O"  on  page  58.  The  delault  Is  False. 
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■  PoBix_Coi9liaiit;  Specifies  whether  certain  behavior 
described  the  IEEE  Portable  Operating  S3«tem  Interface 
(POSIX)  Is  required.  If  True,  the  following  operational  char¬ 
acteristics  of  progrnins  compiled  and  linked  under  Rational 
Apex  are  affected: 

a  The  program  can  control  only  those  UNIX  signals  explic¬ 
itly  allowed  by  POSIX.5  3.3.3. 1  (those  not  “reserved  for 
the  Ada  implementation"). 

a  The  program  cannot  install  an  interrupt-entry  task  to 
handle  UNIX  signals  that  the  runtime  system  uses,  nor 
can  It  install  both  an  interrupt-entry  task  and  an  Ada 
procedural  signal  handler  for  the  same  signal  (POSIX.5 
3.3.2.1(963)). 

□  The  default  values  for  the  Form-parameter  fields  in  the 
Ada-predefined  I/O  packages  are  the  POSIX.5  values 
rather  than  the  Apex  values,  as  descrilsed  in  “Field 
Defaults"  on  page  50. 

The  default  is  True. 

■  Praai^tiva^Schaduling:  Specifies  whether  preemptive 
(asynchronous)  task  scheduling  takes  place.  If  True,  all 
tasks  spawned  by  the  main  program  are  scheduled  preemp¬ 
tively.  The  default  is  False.  Task  scheduling  is  described  in 
Chapter  5,  “Ada  Tasking  in  UNIX.* 

■  Si9nal_stack_Siz8:  An  integer  expression  greater  than  or 
equal  to  2.048  (2  Kb)  that  specifies  the  size  of  the  signal 
stack,  in  bytes.  The  Ration^  Ada  runtime  system  uses  this 
stack  for  handling  runtime  signals,  and  the  debugger  uses 
this  stack  for  special  type  display.  If  not  specified,  the 
default  signad  stack  size  is  64  Kb.  When  the  program  is  run 
under  the  debugger,  the  default  stack  size  is  Increased  to 

2  Mb. 

■  Stack_Size:  A  static  integer  expression  greater  than  or 
equal  to  2.048  (2  Kb)  that  specifies  the  size  of  the  main  task 
stack,  in  bytes.  If  not  specified,  the  default  stack  size  Is 

2  Mb. 

■  Task_Prlority_D«£ault:  An  expression  of  type  System- 
. Priority  that  specifies  the  priority  for  any  task  without  a 
pragma  Priority.  The  default  is  the  same  as  the  main  task's 
priority:  If  the  main  task  is  not  given  a  priority,  the  default 
is  127. 
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■  Taak_8tack_SiK«_D«fault:  A  static  integer  expression 
greater  than  or  equal  to  2.048  (2  Kb)  that  specifies  the  size, 
in  b3rtes.  of  the  stack  for  any  task  without  a  ’Storage_Slze 
representation  clause.  The  default  is  64  Kb. 

■  Tijn_Sllca:  A  nonnegative  expression  of  type  Standard- 
•Duratlon  that  determines  the  quantity  of  time  to  allocate  to 
an  executing  task.  By  default,  or  if  the  value  is  zero,  no  time 
slicing  Is  used.  This  hats  an  effect  only  in  conjunction  with 
preemptive  scheduling;  otherwise,  it  Is  ignored. 

Usage 

Use  pragma  Main  after  the  end  of  the  unit  body  of  any  pa¬ 
rameterless  library-unit  procedure  to  designate  it  as  a  main 
program. 

Pragma  Main  can  have  two  effects.  It: 

■  Causes  the  unit  to  be  linked  automatically  if  it  Is  in  the 
directory  or  view  for  which  you  have  requested  linking; 
main  units  Without  pragma  Main  eure  not  linked  unless 
explicitly  requested. 

■  Permanently  specifies  the  size  of  various  code  sections  and 
the  mode  of  operation  for  the  executable  program  resulting 
firom  a  link. 

Example 

Use  pragma  Main  as  shown: 

proesdur*  Show_M«in  is 
bsgin 

Do_SoMthlng ; 
snd  ShowJHsln; 

pragma  Main  (Staek_8isa  *>  10*1024);  --Cbangs  to  10  Kb 

Notes 

■  All  arguments  can  be  specified  using  Apex  session  switches 
to  change  the  options  dynamically  at  runtime.  The  switches 
have  the  same  names  as  the  arguments,  in  all  uppercase, 
with  the  prefix  APEX_.  Ebqiliclt  use  of  an  argument  on 
pragma  Main  overrides  the  switch  values. 
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References 

■  libraiy  unit.  LRM  10.1 

■  main  program.  LRM  10.1 

■  heap  and  stack  allocation.  “Miscellaneous  Memory  Manage¬ 
ment'  on  page  64 

Pragma  Must_Be_Constrained 

Indicates  whether  formal  private  and  limited  private  types 
within  a  generic  formal  part  must  be  constrained  or  have 
deteult  values.  The  syntax  is: 

prmgam  MU8T_BB_COaSTI(AIHBD 
(eoiiditioa_iist) ; 

Arguments 

■  condition_limti  A  comma-separated  Ust  of  conditions 
that  specifies  a  set  of  types  and  whether  each  set  must  be 
constrained  or  have  default  values.  Each  element  of  the 
condition  list  has  the  format: 

[eeaditiea  »]  typm__id_limt 
where; 

a  condition:  Can  be  either  YES  or  NO.  If  omitted,  the 
default  is  YES.  Determines  the  setting  for  all  types  in  the 
following  type  ID  list. 

□  t  jrp«_id_iist:  A  comma-sepmated  list  of  formal  private 
or  limited  private  types.  These  types  must  be  defined  in 
the  same  formal  part  as  the  pragma. 

Usage 

Use  pragma  Must_Be_Constrained  to  specify  how  you  intend  to 
use  the  formal  parameters  in  a  generic  specification. 

Each  condition  controls  the  types  in  the  following  type  ID  list, 
until  the  next  occurrence  of  a  condition.  Consider  this  example: 

pragau  Mu«t_B«_Coastr*in«d 

(Typ«_l,  X<^>Typ«_2,  Typ«_3,  IKS»>Typ«_4,  Typa_5); 

At  the  beginning  of  the  list,  a  condition  is  not  specified,  so  TES 
is  assumed:  hence.  Typc_l  is  constrained.  NO  controls  the 
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following  type  ED  list  which  includes  Type_2  and  'iype_3: 
hence,  they  are  unconstrained.  TBS  controls  the  remaining  type 
ID  list,  so  Type_4  and  Type_5  are  constrained. 

Notes 

If  the  condition  NO  is  specified,  any  use  in  the  body  that 
reqvilres  a  constrained  type  will  generate  a  semantic  error.  If 
YES  is  specified,  any  instantiations  that  contain  actual  param¬ 
eters  that  req\ilre  constrained  types  will  generate  semantic 
errors  if  the  actual  parameters  are  not  constrained  and  have  no 
default  values. 

References 

■  constrained  private  type.  LRM  7.4.2 

■  generic  formal  type.  LRM  12 

■  matching  rules  for  formal  private  types.  LRM  12.3.2 

■  limited  private  type.  LRM  7.4.4 

■  private  type  as  generic  formal  type,  LRM  12.1.2 

Pragma  Slgnal_Handler 

Installs  an  Ada  procedure  as  a  UNIX  signal  handler.  The  syntax 
is: 


prsgw  8I6HAL_BAHDLBR 
(>M(B  » 

SXGKAIi  >>  iat«9«r_MprM0ioa) ; 

Arguments 

■  Nau;  The  simple  Ada  name  of  the  signal-handling 
procedure. 

■  Signal:  A  nonstadc  integer  expression  specifying  the  UNIX 
signal  number  to  be  handled  by  the  specified  procedure. 

Usage 

Elaboration  of  the  pragma  hats  the  effect  of  installing  the  spec¬ 
ified  procedure  as  a  signal  handler  for  the  given  signal;  subse¬ 
quent  occurrences  of  the  specified  signal  will  cause  the 
specified  procedure  to  be  invoked. 
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The  pragma  and  the  procedure  body  must  occur  in  the  same 
declarative  part,  with  the  pragma  following  the  procedure  body. 
This  prevents  the  installation  of  a  procedure  whose  body  has 
not  yet  been  elaborated. 

See  “Ada  Procedural  Signal  Handlers"  on  page  43  for  details  on 
the  construction  of  the  procedure. 

References 

■  simple  name.  LRM  4.1 

■  declarative  part.  LRM  3.9 

Pragma  Suppress_AII 

Suppresses  all  permitted  runtime  checks.  The  syntax  is: 

pr*9M  80PPRB88_AIJ.t 

Arguments 

None. 


Usage 


Use  pragma  Suppress_All  to  create  the  seune  effect  as  edl  of  the 
following: 


pragma  Suppraas 
pragma  Suppraas 
pragaw  Suppraas 
pragma  Suppraas 
pragaw  Suppraas 
pragma  Suppraas 
pragma  Suppraas 
pragma  Suppraas 
pragma  Suppraas 


(Aocaaa_Chaek) ; 
(Dlserimlnant_Cbaek) ; 
(Dlvlsioa_Chack) f 
(Blaboration_Cback) ; 
(ladaxjCbaek); 
(Langtb_Cback) ; 

(Ovarf low^Cbaek) ; 

( Storaga_Cback ) ; 

( RaagajCbaek ) ; 


Notes 

■  Pragma  Suppress_All  has  no  effect  in  a  package 
specification. 

■  The  pragma  must  appear  immediately  within  a  declarative 
part. 
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Rttferences 

■  suppressing  checks.  LRM  11. 

Pragma  Suppress_Elaboration_Checks 

Suppresses  all  elaboration  checks  In  a  given  compilation  unit. 
The  syntax  Is: 

pragma  8uppraas_aiaboration_Chaeka; 

Arguments 

None. 

Usage 

Use  pragma  Suppress_Elaboratlon_Checks  after  the  end  of  the 
unit  body  of  any  compilation  unit  to  suppress  elaboration 
checks  for  all  subprograms  in  that  unit.  This  is  equivalent  to 
placing  a  named  pragma  Suppress  (Elaboration_Check)  on 
each  subprogram  in  the  unit. 

References 

■  suppressing  checks.  LRM  11.7 


Attributes 


Table  10-3  summarizes  all  implementation -defined  attributes 
in  Rational  Ada.  Each  attribute  is  described  In  more  detail  in 
the  following  subsections. 


Tablt  10-3  Implementatlon-D^ntd  Attribute* 


Attrltrate 

Meaning 

'Compiler_Key 

Identifies  the  compiler  used  to  generate  code 
for  the  specified  object 

’CompUerVerslon 

Yields  the  version  of  the  compiler  used  to  gen¬ 
erate  code  for  the  specified  object 

'Oope_Address 

Yields  the  address  of  the  dope  vector  for  an 
array  object 
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Table  JOS  Implementation-D^ftned  Attribute*  (Continued^ 


Attxltrate 

Meaning 

'Dope_Size 

'nelds  the  size  of  the  dope  vector  for  an  array 
object 

■Entiy_Number 

Uniquely  Identifies  an  entry  or  generic 

'Homogeneous 

Specifies  whether  objects  in  a  collection  are  of 
uniform  size 

■'rypc_Key 

Uniquely  Identifies  a  type 

’Compiler_Key 

For  a  prefix  N  that  denotes  the  name  of  an  entity.  N '  Conpiler- 
_Key  yields  the  full  pathname  of  the  compiler  key.  which  Indi¬ 
cates  the  compiler  that  was  used  to  generate  code  for  the  unit 
containing  the  definition  of  N. 

The  entity  named  by  N  can  be  a  program  unit  (package,  subpro¬ 
gram.  task,  or  generic),  an  object  (variable,  constant,  named 
number,  or  parameter),  a  type  or  subtype  (but  not  an  Incom¬ 
plete  type),  or  an  exception. 

The  value  returned  by  this  attribute  is  of  type  String;  for 
example.  ” /xiiv_liom/k«ys/ada_rational_rs6k_aiz ” . 

This  attribute  can  be  used  for  nmtime  detection  of  incompati¬ 
bilities  in  data  representation.  It  typically  is  used  when  passing 
messages  over  a  network  to  ensure  that  the  reader  and  writer 
agree  on  how  to  interpret  the  message.  See  also  'Compiler- 
_Version. 

’Compiier_yersion 

For  a  prefix  N  that  denotes  the  name  of  an  entity.  N '  Conpilar- 
_VarBion  jdelds  the  version  of  the  compiler  that  was  used  to 
generate  code  for  the  unit  containing  the  definition  of  N. 

The  entity  named  by  N  can  be  a  program  imlt  (package,  subpro¬ 
gram.  task,  or  generic),  an  object  (variable,  constant,  named 
number,  or  parameter),  a  type  or  subtype  (but  not  an  incom¬ 
plete  type),  or  an  exception. 
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The  value  returned  by  this  attribute  Is  of  type  string:  for 
example.  ”11.4.0”. 

This  attribute  can  be  used  for  runtime  detection  of  incompati¬ 
bilities  in  data  representation.  It  typically  Is  used  when  paissing 
messages  over  a  network  to  ensure  that  the  reader  and  writer 
agree  on  how  to  interpret  the  message.  See  also  ■Compiler_Key. 

’Dope_Addre8s 

For  an  array  object  A.  A'I>ops_Addraas  yields  the  address  of 
the  dope  vector  that  describes  A.  The  value  Is  of  type  System- 
.Address.  If  the  object  denoted  by  A  has  no  dope  vector,  this 
value  Is  0. 

This  attribute  can  be  used  In  conjunction  with  ’Dope_Slze  for 
retrieving  information  about  the  object,  as  when  reconstructing 
the  array  when  passing  messages  over  a  network.  See  “Dope 
Vectors'  on  page  76  for  additional  information. 


’Dope_Slze 

For  an  array  object  A.  A '  Dops_slss  yields  the  size  in  bits  of  the 
dope  vector.  The  value  is  of  type  Untversal_Integer. 

A  positive  value  is  always  returned,  whether  or  not  the  object 
denoted  by  A  has  a  dope  vector.  Use  ’Dope_Address  to  deter¬ 
mine  whether  the  dope  vector  actually  exists. 

This  attribute  can  be  used  for  retrieving  information  about  the 
object,  as  when  reconstructing  the  array  when  passing 
messages  over  a  network.  See  "Dope  Vectors"  on  page  76  for 
additional  information. 

’Entry_Number 

For  a  prefix  E  that  denotes  a  task  entry  or  generic  formal 
subprogram,  B '  EDtz7_RuBb«r  yields  a  Unlversal_lnteger  value 
that  uniquely  Identifies  the  entity  denoted  by  E. 

’Homogeneous 

For  a  prefix  T  that  denotes  an  access  type.  T '  Honoganaous 
yields  a  Boolean  value.  The  value  returned  is  True  If  all  objects 
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in  the  collection  will  always  have  the  same  constraints.  The 
converse,  however,  is  not  true. 

Appfylng  this  attribute  to  a  type  that  is  not  an  access  value  is  a 
semantic  error. 

Note  that  the  attribute  is  a  property  of  the  type,  not  of  the 
subtype.  Thus,  for  any  access  t3rpe  T.  T '  Honoganaous  yields  the 
same  value  as  T '  Basa '  Hoaoganaous. 

For  example; 

typa  T1  la  aceaaa  String  (1..10)} —  T1 * Hoa»ganaoua-Trua 

typa  T2  la  aceaaa  String;  —  T2 ‘Bonoganaeua^Falaa 

typa  T3  la  naw  T2  (1  ..  10);  —  T3 ‘Boaoganaoua-Falaa 

typa  T4  la  natt  Tl;  —  T4  ’  Boaoganaoua-Trua 

At  the  implementation  level,  the  attribute  indicates  whether 
constraint  information  is  stored  with  allocated  objects. 


’7Vpe_Key 

For  a  prefix  T  denoting  a  type  name.  T '  Typa_Kay  yields  a  string 
that  uniquely  Identifies  type  T.  This  attribute  typically  Is  used 
when  passing  messages  of  a  given  type  over  a  network  to  ensure 
that  the  reader  and  writer  agree  on  the  type  to  use  wdien  inter¬ 
preting  the  message. 

Attributes  of  Numeric  Types 

This  section  lists  the  values  returned  by  attributes  that  apply 
to  Integer  types. 

integer  Types 

The  attributes  that  apply  to  Integer  types — namely.  'First,  'Last, 
and  'Size — ^yield  the  values  shown  below  for  the  predefined  base 
type: 

Tohte  10-4  Attribute  Values  for  Integer  Types 


Attribute 

Value 

Tlrst 

_23i 

last 

2®’-l 

Size 

32 
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Packages  Standard  and  System 


This  section  contains  the  specifications  for  packages  Standard 
and  System. 

Package  System  (LRM  13.7) 

Psekag*  SystM  is 

typ*  Addrsss  is  priv«t*; 

typ«  Haas  is  ( 8parc_8uBoa ) ; 

8yst«B_Haa«  >  constant  Raaa  8parc_8unoa; 
Storaga_Unit  <  constant  t-  8; 

Haaot7_81aa  .  constant  ■f(2  **  31)  -  1; 

Min_Int  t  constant  i-  -(2  **  31); 

Naz_Znt  s  constant  t-  >(2  **  31)  -  1 

Maz_Di9its  t  constant  i*  15; 

Max  .Mantissa  i  constant  t«  31; 

Pina.Oalta  t  constant  t>  1.0  /  (2.0  **  31); 

Tick  I  constant  1.0  f  60.0; 

subtypa  Priority  is  Zntagar  range  0  . .  255 ; 

Assart ion_Brror  i  aseaption; 

function  To_Addrass  (Vaxua  i  Integer)  return  Address; 
function  To_Integer  (Value  i  Address)  return  Integer; 

function  (Left  i  Address;  Right  i  Integer) 
return  Address; 

function  (Left  <  Integer;  Right  ;  Address) 
return  Address; 

function  (laft  i  Addresa;  Kight  i  Address) 
return  Integer; 

function  (Left  i  Address;  Right  i  Integer) 
return  Address; 

function  **<"  (Left,  Right  i  Address)  return  Boolean; 
function  (Left,  Right  i  Address)  return  Boolean; 

function  ">"  (Left,  Right  i  Address)  "eturn  Boolean; 
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function  ">>"  (Loft,  Right  t  Addrooo)  roturn  Booloon; 

—  Tho  funetiona  oboTo  oro  unsigned  in  nature.  Neither 

—  NuBerie_Brror  nor  Conetraint_Brror  will  ever  be 

—  propagated  by  these  functions. 

— ■  Consequently, 

To_Address  (Integer' First)  > 

Te_Addross  ( Integer ' Last ) ; 


—  and 


To_Addreas  (0)  <  To_Address  (-1); 


—  The  unsigned  range  of  Address  includes  values  that 

—  are  larger  than  those  isiplied  by  Hea»ry_Sise. 

Addreas_Zero  i  constant  Address; 

Null_Address  t  constant  Address; 

Mo_Addr  t  constant  Address; 

private 


type  Address  is  new  Integer; 


Address_Zero  i  constant  Address  0; 
Null_ 'ddress  i  constant  Address  i*  0; 
No^Addr  I  constant  Address  0; 


pragma  Suppress  (Blaboration_Checlc, 
pragma  Suppress (Blaboration_Check, 
pragma  Suppress (Blaboratioa_Cbeek, 
pragma  SuppresB(Blaboration_Cbeek, 
pragma  Suppress (81aboration_Chack, 
pragma  Suppress (Blaboration_Cbeek, 
pragma  Suppress (Blaboration_Cback, 
On  System.To_Address) ; 
pragma  Suppress (Blaboration_Check, 
On  >>  System. To_Integer) ; 


On 

■> 

System. 

On 

m> 

System. 

On 

m> 

System. 

On 

-> 

System. 

On 

■> 

System. 

On 

m> 

System. 

pragma  Inline(SystaB. '■f" ) ; 
pragma  Inline(Syatem. 
pragma  Inliae(System. ; 
pragma  Inline(8ystam. "do") ; 
pragma  Inline(Systaai. ’<”); 
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pragma  lnllna(S7stam. *<>* ) ; 
pragma  Inllna(8ystam.To_Jlddraaa) ; 
pragma  Inliaa(8Tatam.So_Intagar) ; 

and  8y8tami 

Package  Standard  (LRM  Annex  C) 

paekaga  8taadard  ia 

typa  *UBi'varsal_Zntagar*  is  ... 
typa  *Univarsal_Raal*  ia  ... 
typa  *Univaraal_Flzad*  ia  ... 
typa  Boolaan  ia  (Palaa,  Trua); 

typa  Intagar  ia  ranga  -2147483648  ..  2147483647; 
typa  Float  ia  digita  6 

ranga  -((2.0  **  128)  -  (2.0  •*  104))  .. 

((2.0  **  128)  -  (2.0  **  104));—  about  3. 484-38 
typa  Z.ong_Float  ia  digita  15 

ranga  -((2.0  **  1024)  -  (2.0  •*  971))  .. 

((2.0  **  1024)  -  (2.0  **  971));  —  about  1.88+308 

aubtypa  Natural  ia  Intagar  ranga  0  ..  2147483647; 
aubtypa  Poaitiva  ia  Intagar  ranga  1  ..  2147483647; 
typa  Duration  ia  dalta  0.000061035156 
ranga  -131072.00000000  .. 

0131071. 9999389648437500000000 ; 
typa  Charaetar  ia  ... 

paekaga  Aaeii  ia... 

typa  String  ia  array  (Poaitiva  ranga  <>)  of  Cbaractar; 
Conatraint_Brror  <  axeaption; 

Vumaric_Brror  i  axeaption; 

8toraga_Brror  i  axeaption; 

Taakiag_8rror  t  axeaption; 

Program_8rror  i  axeaption; 
typa  *Anytypa*  in 
raoord 
null; 

and  raeord; 
and  Standard; 

The  following  table  shows  the  sizes  of  predefined  Integer  and 
floating-point  types: 
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Tablm  lO-S  Siuu  of  Pnd^ntd  Ntunmrie  Types 


Ada  Type  Name 

Stae 

Integer 

32  bits 

Float 

32  bits 

Long_Float 

64  bite 

Fixed-point  types  are  Implemented  using  32  bits. 

Floating-point  types  are  Implemented  according  to  the  IEEE 
Standard  for  Binary  Floating-Point  Arithmetic  (ANSI/IEEE  Std. 
754-1985). 

Standard.Duratlon  Is  a  32-bit  fixed-point  type  with  a  delta  of 

2-14. 

Representation  Clauses 


Ihls  section  discusses  limitations  on  representation  clauses  in 
the  following  categories: 

■  “Representation-Clause  Error  Handling"  on  page  108 

■  ‘Length  Clauses’  on  page  109 

■  ‘Record  Representation  Clauses  (LRM  13.4)"  on  page  1 10 

■  ‘Enumeration  Representation  Clauses  (LRM  13.3)"  on 
page  110 

■  ‘Change  of  Representation  (LRM  13.6)"  on  page  1 10 
For  related  information,  see  Chapter  9.  ‘Sizes  of  Objects." 

Representation-Clause  Error  Handling 

Normally,  an  invalid  representation  clause  causes  an  error  at 
compile  time  and  prevents  successful  compilation. 

Several  Apex  context  switches,  however,  allow  you  to  specify 
whether  to  treat  certain  classes  of  Invalid  representation 
clauses  as  noniatal  errors  that  allow  successful  compilation 
rather  than  as  errors.  See  Appendix  A.  ‘Switches,"  and  Using 
Rational  Apex  for  details  on  the  following  switches: 
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■  Igaore_Invalld_Rep_Specs:  Affects  the  handling  of  both 
Invalid  and  unsupported  representation  specifications. 

■  Ignore_Unsupported_Rep_Specs:  Affects  the  handling  of 
vmsupported  representation  specifications  only. 

Length  Clauses 

Length  clauses  are  never  allowed  on  derl-^ed  record  t3rpes; 
otherwise,  length  clauses  are  supported  by  Rational  Ada  as 
follows: 

■  The  value  of  a  'Size  attribute  must  be  a  positive  static 
integer  expression.  It  must  be  greater  than  or  equal  to  the 
Tnintimim  size  necessary  to  store  the  largest  possible  value 
of  the  type.  'Size  attributes  are  supported  for  all  scalar  and 
composite  types  with  the  following  restrictions: 


Tallis  lO^  ‘SiMM  Attribute  Reetrietione 


Types 

Legal  Attribute  Values 

Access  and  task 

32 

Composite 

Must  not  imply  compression  of  composite 
components:  such  compression  must  have 
been  explicitly  requested  using  a  length  clause 
or  pragma  Pack  on  the  component  type 

Discrete 

Less  than  or  equal  to  32 

Fixed- point 

Less  than  or  equal  to  32 

Floating-point 

Can  specify  only  the  size  the  type  would  have 
if  there  were  no  clause;  therefore,  the  only 
legal  values  are  32  and  64 

m  'Storage_Size  attributes  are  supported  for  access  and  task 
types.  The  value  given  by  a  'StorageJSlze  attribute  can  be 
any  integer  expression,  and  it  is  not  required  to  be  static. 
■  ‘Small  attributes  are  supported  for  fixed-point  types.  The 
value  given  by  a  'Small  attribute  must  be  a  positive  static 
real  number  that  cannot  be  greater  than  the  delta  of  the 
base  type.  It  need  not  be  a  power  of  2. 
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Enumeration  Representation  Clauses  (LRM  13.3) 

Enumeration,  representation  clauses  are  supported  with  the 
following  restriction: 

■  The  allowable  values  for  an  enumeration  clause  range  from 
Integer'Flrst  to  Integer'Last. 

Record  Representation  Clauses  (LRM  13.4) 

Both  full  and  partial  representation  clauses  are  supported  for 
both  discriminated  and  undiscriminated  records.  Record 
component  clauses  are  not  allowed  on: 

■  Array  or  record  fields  whose  constraint  Involves  a  discrimi¬ 
nant  of  the  enclosing  record 

u  Array  or  record  fields  whose  constraint  Is  not  static 

The  static  simple  expression  In  the  alignment  clause  part  of  a 
record  representation  clause — see  the  Ada  LRM  13.4  (4)— must 
be  a  power  of  2  with  the  following  limits: 

j 

1  <«  •tatle_siapl«_«xpr*8sioB  <•  16 

The  size  specified  for  a  discrete  field  In  a  component  clause 
must  not  exceed  32  bits. 

Change  of  Representation  (LRM  13.6) 

Change  of  representation  is  supported  wherever  it  Is  Implied  by 
support  for  representation  specifications.  In  particular,  ^rpe 
conversions  between  array  types  may  cause  packing  or 
unpacking  to  occur;  conversions  between  related  enumeration 
types  with  different  representations  may  result  in  table -lookup 
operations. 

Implementation-Generated  Names 


The  Ada  LRM  allows  for  the  generation  of  names  denoting 
Implementation -dependent  components  in  records.  No  such 
names  are  visible  to  the  user  for  Rational  Ada. 
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j 

Address  Clauses  (LRM  13.5) 


Address  clauses  cannot  be  applied  to  task  types.  No  other 
restrictions  are  placed  on  address  clauses. 

An  address  clause  can  be  attached  to  a  task  entry  only  when 
the  task  entry  Is  used  for  signal  (interrupt)  catching:  however. 
In  this  case,  the  task  entry  must  be  available  at  the  time  of  the 
signal.  See  the  discussion  of  pragma  Signal_Handler  on 
page  99  and  “Interrupt-Entry  Tasks"  on  page  40  for  additional 
Information. 

Values  of  address  clauses  are  not  checked  for  validity.  No  check 
Is  made  to  determine  whether  an  address  clause  causes  the 
overlay  of  objects  or  of  program  units. 

Unchecked  Programming 


Unchecked  Storage  Deallocation  (LRM  13.10.1) 

Unchecked  storage  deallocation  is  implemented  by  the  Ada 
LRM -defined  generic  function  Unchecked_Deallocatlon.  This 
procedure  can  be  instantiated  with  an  object  type  and  its 
access  type,  resulting  in  a  procedure  that  deallocates  the 
object’s  storage.  Objects  of  any  type  can  be  deallocated. 

'The  storage  reserved  for  the  entire  collection  associated  with  an 
access  type  is  reclaimed  when  the  program  exits  the  scope  in 
which  the  access  type  is  declared.  Placing  an  access-type  decla¬ 
ration  within  a  block  can  be  a  usefiil  implementation  strategy 
when  conservation  of  memory  is  necessary  within  a  collection. 
Space  on  the  free  list  is  coalesced  when  objects  are  deallocated. 

Erroneous  use  of  dangling  references  ms  be  detected  in 
certain  cases.  When  detected,  the  Storage_Error  exception  is 
raised.  Deallocation  of  objects  that  were  not  created  through 
allocation  (that  is.  throu^  Unchecked_Conversion)  may  also 
be  detected  in  certain  cases.  aUso  raising  Storage_Error. 

Unchecked  Type  Conversion  (LRM  13.10.2) 

Unchecked  type  conversion  is  Implemented  by  the  generic 
function  Unchecked_Converslon  defined  by  the  Ada  LRM.  This 
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function  can  be  instantiated  with  source  and  target  types, 
resulting  in  a  function  that  converts  somce  data  values  into 
ta^et  data  values. 

Unchecked  type  conversion  moves  storage  units  from  the 
source  object  to  the  target  object  sequentially,  starting  with  the 
lowest  address.  Transfer  continues  imtll  the  source  object  is 
exhausted  or  the  target  object  runs  out  of  space.  If  the  target  is 
larger  than  the  soiuce.  the  remaining  bits  are  undefined. 
Depending  on  the  target-computer  architect,  the  result  of 
conversions  may  be  right-  or  left-justified. 

Restrictions  on  Unchecked  Type  Conversion 

The  following  restrictions  apply  to  unchecked  type  conversion: 

■  The  target  type  of  an  unchecked  type  conversion  cannot  be 
an  unconstrained  array  type  or  an  unconstrained  discrimi¬ 
nated  type  without  defkult  discriminants. 

■  Internal  consistency  among  components  of  the  target  type 
is  not  guaranteed.  Discriminant  components  may  contain 
illegal  values  or  be  inconsistent  with  the  use  of  those 
discriminants  elsewhere  in  the  type  representation. 

Input/Output  Packages 


The  Ada  language  defines  specifications  for  four  I/O  packages: 
Sequentlal_Io,  Dlrect_Io.  Low_Level_Io.  and  Text_Io.  The 
following  subsections  explain  the  implementation-dependent 
characteristics  of  those  four  packages  provided  with  Rational 
Ada. 

Sequential  Jo  (LRM  14.2.2  and  14.2.3) 

For  the  Read  procedure  of  Sequential_Io.  the  Data_Error  excep¬ 
tion  is  raised  only  when  the  size  of  the  data  read  fi'om  the  file  is 
greater  than  the  size  of  the  out  parameter  Item. 

POSIX  Compliance 

The  Form  parameter  on  subprograms  in  Sequentialjo  is 
compliant  with  the  POSIX.5  standard  to  the  extent  described  in 
Chapter  7.  “Files  and  I/O." 
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Direct  Jo  (LRM  14.2.4) 

Package  Direct  Jo  may  not  be  instantiated  with  any  type  that  is 
either  an  unconstrained  array  type  or  a  discriminate  record 
type  without  default  discriminants.  A  semantic  error  is  reported 
when  an  attempt  Is  made  to  install  any  unit  that  contains  an 
Instantiation  in  which  the  actual  type  is  such  a  forbidden  type. 

For  the  Read  procedure  of  Direct  Jo,  no  check  Is  performed  to 
ensure  that  the  data  read  from  the  file  can  be  interpreted  as  a 
value  of  the  Element_'IVpe. 

Specification  of  Package  Direct  Jo  (LRM  14.2.5) 

The  declaration  of  the  type  Count  in  package  Direct  Jo  is: 

typ*  Count  is  now  Intogor  rnngo  0  ..  Intogor'Lnst  / 
Bloaiont_T7po '  Siso} 

where  Element_Type  is  the  generic  formal  type  parameter. 

POSiX  Compliance 

The  Form  parameter  on  subprograms  in  Direct  Jo  is  compliant 
with  the  POSIX.  5  standard  to  the  extent  described  in  Chapter 
7,  “Files  and  I/O." 

Low.LeveIJo  (LRM  14.6) 

Package  Low_Level  Jo  is  not  provided  with  Rational  Ada. 

Text  Jo  (LRM  14.3) 

The  Text  Jo  default  input  and  output  files  are  associated 
with  the  UNIX  standard  input  and  standard  output  paths, 
respectively. 

Specification  of  Package  Text  Jo  (LRM  14.3.10) 

The  declaration  of  the  type  Count  in  Text  Jo  is: 

typs  Count  Is  now  intogor  rnngo  0  ..  I_000_000_000 > 

The  declaration  of  the  subtype  Field  in  Text  Jo  is: 

subtypo  Piold  is  Intogor  rnngo  0  ..  Intogor ' Lost ; 
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Chapter  1 0  LRM  Appendix  F:  lmplementation>Oependent  Characteristics 

RIe-Management  Operations 

Tbe  opeiatlona  of  Get  and  Put  are  as  described  in  the  Ada  LRM. 

Data  written  using  Put  and  Put_Line  is  not  interpreted  in  any 
&shion.  Data  written  using  Put_Line  is  followed  the  line 
terminator  AsciLLf. 

Data  read  using  Get  and  Get_Line  is  not  interpreted  except  that 
the  line  terminator,  AsciLLf.  and  the  page  terminator.  Ascii.Ff. 
are  removed  from  the  input  stream. 

POSIX  Compliance 

The  Form  parameter  on  subprograms  in  Text_Io  is  compliant 
with  the  POSIX.5  standard  to  the  extent  described  in  Chapter 
7.  “Files  and  I/O.’ 

Other  Implementation-Dependent  Features 

Machine  Code  (LRM  13.8) 

Machine-code  insertions  are  not  supported  at  this  time. 
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MACRO  PARAMETERS 


This  appendix  contains  the  macro  parameters  used  for  customizing  the  ACVC. 
The  meaning  and  purpose  of  tliese  parameters  are  explained  in  (UG89].  The 
parameter  values  are  presented  in  two  tadjles.  The  first  table  lists  the 
values  that  are  defined  in  terms  of  the  maximum  input-line  length,  vhich  is 
the  value  for  $MAX_IN_LEN — also  listed  here.  These  values  are  expressed  here 
as  Ada  string  aggregates,  vdiere  "V"  represents  the  maucimum  input-line  length. 

Macro  Parameter  Macro  Value 


$MAX_1N_LEN 

254  —  Value  of  V 

$BIG_rDl 

(1..V-1  ->  'A',  V  ->  '1') 

$B1G_ID2 

(1..V-1  ->  'A',  V  ->  '2') 

$BIG_ID3 

(1..V/2  ->  'A' )  &  '3'  & 
(1..V-1-V/2  ->  'A') 

$BIG_ID4 

(1..V/;:  ->  'A')  &  '4'  & 

(1  .V-l-V/2  ->  'A' ) 

$BIG_INT_LIT 

(1..V-3  ->  '0')  &  "298" 

$BIG_REAL_LIT 

(1..V-5  ->  '0')  &  "690.0" 

$BIG_STRING1 

&  (1..V/2  ->  'A')  & 

$BIG_STRING2 

&  (1.. V-l-V/2  ->  'A')  & 

$BLANKS 

(l.,V-20 

$MAX_LEN_INT_BASED_ 

LITERAL 

"2;"  &  (1..V-5  ->  '0')  &  "11 

$MAX_LEN_REAL_BASED_LITERAL 

"16;"  &  (1..V-7  ->  'OM  &  "F.E:" 
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$MAX_STRING_LITERAL  &  (1..V-2  ->  'A')  & 

Hie  following  t2djle  lists  all  of  the  other  macro  parameters  and  their 

respective  values. 

Macro  Parameter  Macro  Value 

$ACC_SIZE  32 

$AL1GNMENT  1 

$COUNT_LAST  1000000000 

$DEFAULT_MEM_SIZE  2147483647 

$DEFAULT_STORJUNIT  8 

$DEFAULT_SYS_NAME  SPARC_StJNOS 

$DELTA  DOC  0.000_000_000_465_661_287_307_739_257_812_5 

$E2miY_ADDRESS  SYS'ITM.TO_ADDRESS  (30) 

$ENTRY_ADDRESS1  SYSTEM. TO_ADDRESS  (31) 

$ENTRY_ADDRESS2  SYSTEM. TO_ADDRESS  (2) 

$F1ELD_LAST  2147483647 

$FILE_TERMINATOR  '  ' 

$FIXED_NAME  NO_SUCH__TYPE 

$FLQAT_NAME  NO_SUCH_TYPE 

$FORM_STRING 

$FORM_STRING2  "CAN^Kn’_RESTRICT_FILE_CAPACITY" 

$GREATER  THAN  DURATION 

1.0 

$Ca^TER  THAN  DURATION  BASE  LAST 

T31_073.0 

$GREATER  THAN  FLQAT_BASE  LAST 

i.iJesoo 

$GREATER  THAN  FLQAT_SAFE  LARGE 

3.IE38 
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$GREATER_THAN_SHORT_FLQAT_SAFE  LARGE 

1.0E308 

$HIGH_PRIORITY  255 

$ILLEGAL_EXTERNAL_FILE_NAME1 

BAD/_CHARACTERS 

$  ILLBGAL_EXTERNAL_FILE_NAME2 

CONTAINS/JWILDCARDS 

$  INAPPROPRIATE  LINE_LENGTH 

-1 

$INAPPROPRIATE_FAGE_LENGTH 

-1 

$INCLUDE_PRAGMA1  PRAOIA  INCLUDE  (  "A28006D1.TST" ) ; 

$1NCLUDE_PRAGMA2  PRAGMA  INCLUDE  ( "B28006D1 .TST" ) ; 

$INTEGER_FIRST  -2147483648 

$INTEGER_LAST  2147483647 

$INTEGER_LAST_PLUS_1  2147483648 

$INTERFACE_LANGUAGE  C 

$LESS_THAN_DURATION  -1.0 

$LESS_THAN_DURATICN_BASE  FIRST 

-lll_073.0 

$LINE_TERMINATOR  ASCI I . LF 

$LOW_PRIORITY  0 

$MACHINE_CODE_STATEMENT 

NULL; 

$MACHINE_CODE_TYPE  NO_SUCH_TYPE 

$MANTISSA_DOC  31 

$MAX_DIGITS  15 

$MAX_INT  2147483647 

$MAX_INT_PLUS_1  2147483648 

$MIN_INT  -2147483648 

$NAME  NO_SUCH_TYPE 
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$NAME_LIST 

SPARC_SUNOS 

$NAME_SPECIFICATIQN1 

X2120A 

$NAME_SPECI FICATICN2 

X2120B 

$NAME_SPECIFICATI0N3 

X3119A 

$NEG_BASED_INT 

16#FFFFFFFE# 

$NEW_MEM_SI2E 

2147483647 

$NEM_STOR_UNIT 

8 

$NEW_SYS_NAME 

SPARC_SUNOS 

$PAGE_TERMINATOR 

ASCII.FF 

$RECORD_DEFINITIC»« 

NEW  INTEGER; 

$RECORD_NAME 

NO_SUCH_MACHINE_CC®E_TyPE 

$TASK_SI2E 

32 

$TASK_STORAGE_SIZE 

8192 

$TICK 

(1.0/60.0) 

$VARIABLE_ADDRESS 

FCNDECL .  ADDRESSO 

$VARIABLE_ADDRESS1 

FCNDECL . ADDRESSl 

$YARIABLE_ADDRESS2 

FCNDECL .ADDRESS2 

$YOUR_PRAGMA 

EXPORT_OBJECT 
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APPENDIX  B 

COMPILATIOJ  AND  LINKER  OPTIOJS 


The  compiler  and  linker  options  of  this  Ada  implementation,  as  described  in 
this  Ap^ndix,  are  provided  by  the  customer.  Unless  specifically  noted 
otherwise,  references  in  this  appendix  are  to  compiler  documentation  and  not 
to  this  report. 
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